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DETAILED ACTION 

1. This action is responsive to the application filed 3/8/2006. 

Claims 1-69 have been submitted for examination. 

Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-7, 15-18, 26, 36-38, 55-61, and 69 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kuzara et al., USPN: 5,450,586 (hereinafter Kuzara) and fiuther in view of 
Held, USPN: 5,889,988 (hereinafter Held). 

As per claim 1, Kuzara discloses a method for increasing security of a software program by 
obfiiscation of program execution flow, wherein the software program is executed on a 
computer system that includes a user-level protected mode and a kemel-level unprotected 
mode (Figs. 9-10), the method comprising the steps of: 

identifying critical code segments ( e.g. code marker, routine 1010, task switch - col. 16, 
lines 19-48) to be hidden in the software program (e.g. col. 5, lines 30-49; col. 15, lines 30-39 - 
Note: black box reads on kernel execution being hidden); 

executing non-critical portions of the software program in the user-level protected mode 
(e.g. user code 900 - Fig. 10); 

executing the critical code segments (e.g. kernel 902 - col. 16, lines 38-51) , thereby 
hiding execution of the critical code segments from a debugger program (Note: the use of kernel 
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execution (real-time "black box") code being separated (or hidden) from the user code in the 
Kuzara's debug and code marker insertion ( e.g. col. 5, lines 30-49) discloses a concept of hiding 
from the user code environment). 

But Kuzara does not explicitly mention about executing critical code segments within 
respective exception handlers; however teaches about special entry/exit points related to the use 
of markers to address low intrusion process for task switching and exception occurrences (e.g. 
task switching ... exception event -col. 5, lines 6-1 1). Analogous to using markers to support low 
intrusion task switching into a debug kernel execution as by Kuzara (see: task . . .entered . . .exited 
- col. 16, lines 19-48) and for use in addressing visible critical points (see Kuzara: col. 4, lines 
31-42; col. 5 lines 4-13) or exceptional events as mentioned above. Held, in a debugger of 
embedded system, uses predefined breakpoint as well as detecting and executing of such 
breakpoints in a kernel debugger via exception handlers (step 807 - Fig. 8). In light of the 
known concept to use special program handler to address interrupt or exceptional/critical events 
especially in a debugging endeavor as approached by both Kuzara and Held, it would have been 
obvious for one skill in the art at the time the invention was made to implement the marker code 
for exception event or task switching by Kuzara so that it be encompassed in a 
interrupt/exception handler because the use of underlying handler in case of interruption or 
special exception as suggested by Kuzara during user code execution would enable the 
underlying and readily available lower system code (kernel level) to expediently and directly 
address issues being at the root of such exception (see Held: col. 11, line 61 to col. 12, line 5), 
notably when Kuzara has intended for the debugger to operate in user code transparently from 
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kernel black box, i.e. handling of issues without immediate support/intervening from the user 's 
level application. 

As per claim 2, Kuzara does not explicitly disclose inserting an exception set-up handler 
into the software program that sets-up the exception handlers so that the exception handlers will 
be invoked during program execution. It is recognized that Kuzara's code marking via use of 
dynamic insertion ( Fig. 4) or a library code setup would allow kernel code ( see Figs. 9-10) to 
help set up task switching or handling of exceptional events as mentioned above. In view of 
Kuzara's above teaching as well as the user code to pass parameters to allow the OS to mark 
entry and exit points (col. 15, lines 41-53; col. 16, lines 7-15 ) and the rationale as to why 
Kuzara's code marking would be operated within interruption handler as set forth from above, 
the above code insertion to set up marking by Kuzara so that it set up kernel code handlers would 
have made the above claimed limitation obvious for the same reasons as set forth above. 

As per claim 3, combined with Held's teaching, Kuzara also teaches insertion of code 
based on extraction specific parts of source code ( e.g. col. 11, lines 5-9); hence Kuzara has 
disclosed inserting an in-line code segment in the software program, wherein the in-line code 
segment sets up and executes the exception set-up handler during program execution; the 
rationale to set up marker so that marker evokes kemel execution via use of exception handler 
being set forth above in claim 1 . 

As per claim 4, in view of the rationale for obviousness using the teaching by Held, 
Kuzara fiirther includes the step of inserting a kemel level driver ( re claim 1 - Note: a kemel 
routine to set up and evoke handler by Held reads on driver in a OS kemel) in the software 
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program that sets-up the exception handlers so that the exception handlers will be invoked during 
program execution. 

As per claim 5, Kuzara discloses insertion of code in the program source code to set up 
code marker; and kernel code to execute point at which code switch being supported with 
handlers is being deemed obvious as set forth in claim 1 or 4 above. Hence, Kuzara in view of 
Held discloses the step of inserting an in-line code segment in the software program, wherein the 
inline code segment invokes the kernel-level driver, thus causing the exception handlers to be 
invoked during program execution. 

As per claim 6, Kuzara in view of Held disclose using the set-up handler to initiate a set- 
up of breakpoint or marker for code switch such that the critical code segments in the exception 
handlers are executed at appropriate times during the program execution ( re claim 1) but Kuzara 
does not explicitly disclose debug registers. Held discloses using code switch and set up debug 
registers along with breakpoints (e.g. col 10, lines 1 1-28). Based on the rationale to segregate 
user code and kernel level tasks switching as intended by Kuzara when handling area of code at 
which critical points need to be handled more particularly, it would have been obvious for one of 
ordinary skill in the art at the time the invention was made to implement the task switch and 
breakpoints shown by Kuzara with the use of dedicated hardware registers as shown by Held 
because according to Held, this would dedicate special hardware resource per context of a task 
switcher as taught by Kuzara hence obviate or prevent the main processor for being held 
permanently because of some potentially ill-behaved tasks. 

As per claim 7, Kuzara teaches insertion of code in the program source to set up marking 
of code ( re claim 3); hence has disclosed executing the in-line code segment prior to a point in 
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the program flow where any of the critical code segments was removed for placement into the 
exception handlers (e.g. col. 5 lines 4-13 - Note: after the marking is done, code markers is only 
detected later in order to address critical area of code). 

As per claim 15, Kuzara discloses a method for increasing security of a software 
program by obfiiscation of the software program execution flow, the method comprising the 
steps of: 

partitioning the software program into code segments, each code segment having a 
particular location within the program execution flow ( e.g. Fig. 7); 

identifying one or more critical code segments (e.g. code marker, routine 1010, task 
switch -col. 16, lines 19-48); 

encapsulating the critical code segments in respective kernel code execution (col. 5, lines 
30-49; col. 15, lines 30-39 - Note: black box reads on kemel execution being segments of code 
being encapsulated away fi-om the user's code); and 

during software program execution, executing the code segments containing the critical 
code segments in their respective relative location (e.g. code marker, routine 1010, task switch - 
col. 16, lines 19-51) within the program execution flow. 

But Kuzara does not explicitly disclose encapsulating in exception handlers; nor does 
Kuzara disclose that the kernel-executed segments are exception handlers, i.e. the exception 
handler containing the critical code segments. But this exception handler limitation as to 
implementing the kemel critical segment execution under an exception handler has been 
addressed in claim 1 above. 
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As per claim 16, Kuzara discloses a method for obfuscation of computer program 
execution flow to increase computer program security, the method comprising the steps of: 

breaking the computer code into a plurality of code segments (Fig. 7), and identifying 
critical code segments to be obfuscated (col. 5, lines 30-49; col. 15, lines 30-39 - Note: black 
box reads on segments being handled by kemel execution, i.e. being obfuscated); 

embedding each of one or more critical code segments within respective first kemel 
execution (coflfe marker, routine 1010, task switch - col. 16, lines 19-48; col. 15, lines 30-39); 

embedding an in-line code segment within a first one of the remaining plurality of code 
segments for setting up and invoking the kemel execution of critical segments (e.g. col. 11, lines 
5-9). 

But Kuzara does not explicitly disclose that first the kemel-executed critical code 
segments are execution of segments within exception handlers, nor does Kuzara disclose 
providing an exception set-up handler to set up operation of the first exception handlers. But 
this limitation as to implementing the kemel critical segment execution under an exception 
handler has been addressed in claim 1 above. 

As per claim 17, the limitation as to provide set-up handler to initiate a set-up of debug 
registers, such that the critical code segments in the exception handlers are executed at 
appropriate times during the program execution, correspond to the subject matter of claim 6; 
hence will incorporate the rationale of rejection as set forth therein. 

As per claim 18, this claim corresponds to claim 7; hence is rejected using the rationale 
as set forth therein. 
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As per claim 26, Kuzara does not explicitly disclose providing entry code for the first 
exception handlers to determine a nature of the exception; but Kuzara disclose various events 
called deemed critical to evoke exception handlers ( col. 4, line 42 to col. 5, line 11). In view of 
the rationale to impart exception handler inside critical kemel code execution as set forth in 
claim 1, and the nature of what type of events to address from Kuzara ( see step 604 - Fig. 6). In 
view of a specific handler as taught from Held's kemel execution (e.g. handler supports task 
specific - col. 7, lines 23-26; Fig. 6), so to support the correct type of exception or debug task 
being passed to a kemel handler, it would have been obvious for one skill in the art at the time 
the invention was made to implement the exception handlers and kemel execution thus 
mentioned above to address debug events as taught by Kuzara so that a provision is implemented 
by means suggested by Held to evoke the correct handlers, i.e. a code to identify the nature of the 
event or type of exception as raised above by Kuzara, because evoking of a specific handler 
would depend on such identification code, such as recognized in Held's teaching. 

As per claim 36, Kuzara discloses a method for obfiiscation of computer program 
execution flow to increase computer program security, the method comprising the steps of: 

partitioning the program into a plurality of non-critical code segments and at least one 
critical code segment (e.g. Fig. 7); 

obfiiscating the critical code segments by embedding each of one of the critical code 
segments within a kemel execution {kernel 902 - col. 16, lines 38-51); 

providing a driver to set up operation of the first kemel execution (e.g. col. 11, lines 5-9) 
embedding an in-line code segment within a first non-critical code segment for invoking the 
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driver when the program is executed (e.g. code marker, routine 1010, task switch - col. 16, lines 
19-51). 

Also as mentioned in claim 1, Kuzara does not explicitly teach segments within kernel 
execution are segments within exception handlers; nor does Kuzara teach setup operation of a 
first exception handler; however, this exception handler limitation has also been addressed using 
the rationale as set forth in claim 1 . 

As per claims 37-38, these claims correspond to claims 6-7, respectively; hence is 
rejected using the rationale as set forth therein, respectively. 

As per claim 55, Kuzara discloses a computer-readable medium containing a software 
program that is to be executed on a computer system that includes a user-level protected mode 
and a kemel-level unprotected mode ( Figs. 9-10), wherein the software program contains critical 
code segments to be obfuscated during program execution flow to increase security of the 
software program, the software program comprising instructions for: 

executing (non-critical portions) of the software program in the user-level protected 
mode; and 

executing (the critical code segment) thereby hiding execution of the critical code 
segments fi-om a debugger program; all of which executing steps having been addressed in claim 
1. 

Also as mentioned in claim 1, Kuzara does not explicitly teach execution of critical 
segments within respective exception handlers; thus, this limitation has also been addressed 
using the rationale as set forth in claim 1. 
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As per claims 56-61, these claims correspond to claims 2-7, respectively; hence are 
rejected using the corresponding rationale as set forth therein. 

As per claim 69, Kuzara discloses a system for obfuscation of program execution flow, 
comprising: 

a computer system including a processor, memory, an operating system that provides 
kernel-level and user-level execution modes (Fig. 1, 5), and debug resources to support the 
generation and processing of exceptions at specified addresses ( Note: this exception at specified 
address is inherent to any computer exceptions that are being handled); and 

an obfuscated program comprising, a plurality of critical code segments encapsulated 
within respective kemel execution segments, and 

a set-up handler for setting up the kemel execution (e.g. col. 5, lines 30-49; col. 15, lines 
30-39) containing the critical code segments are executed in the kemel level mode (kernel 902 - 
col. 16, lines 38-51). 

But Kuzara does not discloses that kemel execution segments are exception handlers; nor 
does Kuzara explicitly discloses a setup code for setting debug registers such that the exception 
handlers containing the critical code segments are executed in the kemel mode. But these 
limitations have been addressed respectively in claim 1 and 17. 

4. Claims 8-14, 19-25, 27, 39-54, and 62-68 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kuzara et al., USPN: 5,450,586 and Held, USPN: 5,889,988 and further in 
view of Cardoza et al., USPN: 5,630,049( hereinafter Cardoza) 

As per claim 8, Kuzara discloses including in-line code segment to install the exception 
set-up handler for a current thread ( re claim 3, in view of Held as set forth in claim 1), such that 
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when an exception occurs, the operating system hands control to the exception set-up handler for 
execution; however, Kuzara does not mention about on an exception handler linked list even 
though teaches about breakpoints or markers being stored in a table ( table 1002 -Fig. 10). The 
setting of breakpoints so that it follows a list a table or a chained list like a linked list is further 
disclosed by Cardoza. Analogous to the breakpoints handling by Held in light of Kuzara, 
Cardoza, in a debug system where user debug commands are generated from the host computer 
to a embedded device for set up breakpoints and wherein breakpoints are handled via message at 
the target system, and further discloses a linked list to maintain user's generated breakpoints (e.g. 
col. 26, lines 29-60). The use of list or table in order to dynamically support/establish points at 
which the kernel code is invoked to establish exception handling switches as mentioned in claim 
1 would be recognized via Kuzara' s teaching; and in view of such, it would have been obvious 
for one of ordinary skill in the art at the time the invention was made to maintain such list or 
table in terms of a linked list as taught by Cardoza, because this would enable Kuzara' s user- 
activated code marking setup call to be informed on the dynamic adding or deleting of 
breakpoints for a particular OS thread, and this is fostered via Cardoza's linked list and its 
usefulness based on known progranuning language usage of such construct (see Cardoza: col 26, 
lines 53-60) 

As per claims 9 and 10, with respect to the rationale of claim 8, the use of linked list by 
Kuzara in view of Cardoza also includes, by virtue of a integral linked list adding/removing 
scheme, the removing ( re claim 9) the exception set-up handler from the linked list after 
execution; and further includes ( re claim 10) inserting each of the exception handlers into the 
linked list. 
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As per claim 11, Kuzara in view of Held discloses when an exception is raised to the 
operating system, handing control down to the layer of code hidden to the user code ( see 
Kuzara: col. 5, lines 30-49; col. 15, lines 30-39). But Kuzara does not explicitly disclose 
handling down to the linked list until one of the exception handlers determines that the exception 
is one that the exception handler is designed to handle. The set up of breakpoints in terms of 
points at which the kernel code would handle critical points via exception handler (using Held) 
as set forth in claim 1, have been recognized to yield benefits from using a set up via a linked list 
as set forth in claim 8; hence the limitation as to hand down to a linked list for such critical 
points to be addressed based on the existence of a marker or breakpoints being still alive ( not yet 
removed) in such list would also have been obvious in light of the rationale of claim 8. 

As per claim 12, in light of the linked list being traversed in order to find out which 
breakpoints remain as to execute under or handle over an exception handler as set forth above, 
Kuzara in view of Held/Cardoza discloses if the exception is one for which the current exception 
handler was designed to handle, executing the critical code segment included in the current 
exception handler. 

As per claim 13, Kuzara discloses a retum after a context switch and exception events 
(e.g. col. 16, lines 19-48; col. 5, lines 4-11) and in light of Held's exception handler with 
restoring of context (e.g. col. 9, lines 52 to col. 10, line 10), this context switch encompasses the 
step of: if the exception is one for which the exception set-up handler was designed to handle, 
setting a retum address for the exception set-up handler when the exception processing 
completes. Hence, in view of the obviousness rationale as set forth in claim 1 , Kuzara in view of 
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Held has disclosed setting a return address for the exception handler when the exception 
processing completes. 

As per claim 14, the concept of daisy chaining a sequence of exception handler falls 
imder the linked list concept as being addressed above in claim 8; hence the claim will 
incorporate the same rationale as set forth therein. 

As per claims 19-21, these claims correspond to claims 8-10, respectively; hence are 
rejected using the corresponding rationale as set forth therein. 

As per claims 22-25, these claims correspond to claims 11-14, respectively; hence are 
rejected using the corresponding rationale as set forth therein. 

As per claim 27, with respect to identifying of the nature of exception handler to use as 
set forth in claim 26, Kuzara does not explicitly disclose including the step of handling the 
exception if the nature of the exception is applicable to the first exception handler, otherwise 
handing exception processing to the next available exception handler. However, the selecting of 
a appropriate handler by searching a first handler then a second handler would also have been 
obvious in view of chaining the handlers as set forth in claim 8 above based on the rationale 
therein. 

As per claims 39-45, these claims correspond to claims 21-27, respectively; hence is 
rejected using the rationale as set forth therein, respectively. 

As per claim 46, the limitation of selecting from the plurality of code segments to 
obfuscate within the first exception handlers based on the value falls under the ambit of 
determining the nature of the exception as set forth in claim 44; and incorporates the rationale as 
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set forth therein (Note: the limitation as to obfuscating the algorithms within the segment, i.e. 
code constructs in a segment, is inherent to the concept of hiding as set forth in claim 1). 

As per claim 47, Kuzara (in Ught of Held - Note: the set up of address retum from a 
exception handUng is inherent to the Held's handler) discloses exception handlers to modify a 
retum address (e.g. col. 18, lines 22-61; col. 16, lines 6-16) to be used after completion of the 
exception processing 

As per claim 48, Kuzara (in light of Held) discloses rearranging non-embedded code 
segments out of normal execution order (col. 18, lines 22-61; col. 16, lines 6-16; Fig. 8), and 
setting exception addresses and retum addresses to ensure proper program sequencing to further 
obfuscate the program execution flow ( Note: the set up of address retum from a exception 
handling is inherent to the Held's handler). 

As per claims 49 and 50, Kuzara discloses including a plurality of code segments within 
the first exception handler to modify exception condition ( Note: set up address for exit and 
retum reads on modifying), such segment including a plurality of code segments (re claim 3: in 
light of the inline code inserting as addressed in claim 3). 

As per claim 51, this claim falls under the ambit of the subject matter about the nature of 
the exception has been addressed in claim 26; hence incorporates the rejection as set forth 
therein. 

As per claim 52, this claim includes additional code for linking exception handlers in a 
chain, all of which having been addressed in claims 8 and 14; hence the claim incorporates the 
rationale of rejection as set forth therein. 
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As per claim 53, the step of setting up exceptions to occur within one or more first 
exception handlers, to be handled by other first exception handlers, to further obfuscate the 
program execution flow would be treated as this falls under the subject matter (linked list/daisy 
chains) of claims 8 and 14; hence would be rejected with the rejection as set forth therein. 

As per claim 54, the step of repeating the embedded exceptions within exception 
handlers such that the required exception processing occurs at a plurality of exception processing 
levels, to further obfuscate the program execution flow would falls under the subject matter of a 
daisy chain or a linked list as set forth in claims 8 and 14; hence would be rejected with the 
rejection as set forth therein. 

As per claims 62-68, these claims correspond to claims 8-14, respectively; hence are 
rejected using the corresponding rationale as set forth therein. 

5. Claims 28-3 1 are rejected under 35 U.S.C. 103(a) as being unpatentable over Kuzara et 
al., USPN: 5,450,586 Held, USPN: 5,889,988; and further in view of Admitted prior Art (APA) 
and Hagimont et al., "Hidden Software Capabilities", Proceedings of the 16^ International 
Conference on Distributed Systems, May 1996, pp. 1-14 ( hereinafter Hagimont) . 

As per claims 28 and 29, Kuzara discloses debugging with user code being separated 
from Operating System lower layer execution by using enhancement to a black box concept for 
hiding from a user level application, i.e. obfuscating the critical code segments to prevent user 
from directly accessing prohibited code segments in the kernel; but does not explicitly state that 
such obfuscating is to prevent reverse engineering ( re claim 28) or to hide anti-piracy algorithms 
( re claim 29). The art of allowing user with certain privileges while hiding or inhibiting access 
to the user or malicious extemal intents was a known concept in software distributing via 
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network's communicating with embedded device by Kuzara (col. 15, lines 20-39; Fig. 2) or Held 
(Fig. 4-5). Other concerns for software application protection as by Kuzara are the software 
piracy issues being also recognized as unwanted code modifications/hacking or access/privilege 
or copyright violation against proprietary application data as above noted; and such piracy is 
recognized via the Admitted Prior Art (APA) as mentioned in the Specifications ( 
BACKGROUND: Pg. 1-2) and raised via the teachings by Hagimont. In an analogous manner to 
protect application software from being violated in the access right scheme so well known in 
software piracy (see APA), Hagimont, in a system to commimicate client-server software 
capabilities or application data transfer like the embedded debug paradigm by Kuzara, discloses 
protection schemes via definition language, capabilities or stubs to avoid malicious and 
unwanted interfering of data between the OS/kemel and the exchanged application data (see 
Introduction: access rights; Chap. 5 - Arias ...hook ...through kernel exception; ch. 2-5). Since 
reverse engineering is one form of piracy wherein software application data is observed via 
malicious intrusion therein in order to make unwanted modifications thereto, it would have been 
obvious for one skill in the art at the time the invention was made to implement the protection 
mode in the debugger environment by Kuzara (in view of the exception handling by Held) so 
that such protection would be implemented via code Kemel exception handling as mentioned 
through Hagimont' s kemel hooks or stubs for hiding software or application data, such 
protection being such as to implement not only anti-piracy (as by APA) and also against reverse- 
engineering; because according to Hagimont the use of extension code and capabilities to hide 
software from such access right violation, the integration of software in development in network 
would be more secure and more flexible ( see Introduction and chap. 2.1). 
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As per claim 30, Kuzara (in light of Held - Note: the set up of address return from a 
exception handling is inherent to the Held's handler) discloses exception handlers to modify a 
return address (e.g. col. 18, lines 22-61; col. 16, lines 6-16) to be used after completion of the 
exception processing 

As per claim 31, Kuzara (in light of Held) discloses rearranging non-embedded code 
segments out of normal execution order (col. 18, lines 22-61; col. 16, lines 6-16; Fig. 8), and 
setting exception addresses and return addresses to ensure proper program sequencing to further 
obfuscate the program execution flow ( Note: the set up of address return from a exception 
handling is inherent to the Held's handler). 

6. Claims 32-35 are rejected under 35 U.S.C, 103(a) as being unpatentable over Kuzara et 
al., USPN: 5,450,586; Held, USPN: 5,889,988; and Hagimont ( in light of APA),"Hidden 
Software Capabilities" and further in view of Cardoza et al, USPN: 5,630,049 

As per claim 32, Kuzara (in light of Held/Hagimont) discloses the step of including code 
handlers to modify exception conditions but does not disclose code within a first handler to 
modify exception conditions to support future exceptions; however, the concept to set up chained 
exception has been addressed using Cardoza; and in light of the daisy chain and linked list 
limitations being addressed in claims 8 and 14, the setup code to provide support for further 
exceptions would have been obvious herein for the same rationale as set forth therein. 

As per claim 33, Kuzara including a plurality of code segments within the first exception 
handler (re claim 3: in light of the inline code inserting as addressed in claim 3). 
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As per claim 34, the claim falls under the ambit of the subject matter about the nature of 
the exception has been addressed in claim 26; hence incorporates the rejection as set forth 
therein. 

As per claim 35, this claim falls under the ambit of the subject matter about linking 
exception in a chain; which has been addressed in claims 8 and 14; hence incorporates the 
rationale as set forth therein. 

Response to Arguments 

7. Applicant's arguments filed 3/8/06 have been fully considered but they are not 
persuasive. Following are the Examiner's observations in regard thereto. 

Rejections under USC 103(a): 
(A) Applicant has submitted that Kuzara's debugger is only to make critical points visible ( 
Appl. Remrks, pg. 20, top para) while the instant invention is a debugging tool that supports 
reverse-engineering; that it can hide critical regions by having these executed by respective 
exception handlers; that program execution may randomly jump, with data structures or values 
appear or disappear, all of which in a transparent way from the standpoint of a debugging user 
(Appl. Rmrks, pg. 20, middle, pg. 21, top 2 para). In response, it seems evident that most of 
these observations are not explicitly recited in the claim; except for the execution of respective 
exception handlers in the purpose of hiding of the identified critical segments. The rejection has 
been set forth based on the broad reasonable interpretation of the elements as they are recited; 
and according to the hiding concept as recited in claim 1, for example, this concept amounts to 
implementation of 2 entities: (i) identifying of critical segments and (ii) executing of these within 
exception handlers. The rejection has pointed to where Kuzara has set up critical points at which 
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some special markers would be intended to invoke special code execution like performing data 
dump or addressing exceptions events (col. 5, lines 4-25); and has used the rationale as to bring 
the teaching by Held to render obvious the use of code handlers to address Kuzara's task 
switching upon encoxmtering markers intended for exception events. Applicant's arguments fail 
to comply with 37 CFR 1 . 1 1 1(b) because they amount to a general allegation that the claims 
define a patentable invention without specifically pointing out how the language of the claims 
patentably distinguishes them from the references. 

(B) Applicant has asserted that the references fail to teach or otherwise suggest the present 
invention; but also teach away because the references teach methods to make debugging more 
visible (AppL Rmrks, pg. 21, bottom, pg. 22 top) by merely hiding operating system from the 
user rather than hidmg critical code segments fi-om a debugger (Appl. Rmrks, pg. 22, middle). In 
response, there no clear information in the claim that by the term 'hiding', the claim necessarily 
enforces that it prevents any operating system firom being hidden to a user; nor does it enforce 
that by executing critical code with exception via handlers, the operating system is necessarily 
visible to the user while only the debugger cannot see the exception handling. Again, the claim ( 
re claim 1) recites ' . . .thereby hiding execution. . . critical code segments from a debugger 
program'(iii) following the step of 'executing the critical code segments within respective 
exception handlers'(iv), the segments having been identified to be hidden. The very act of 
executing within respective exception handlers as provided via the combined teachings ~ of 
markers by Kuzara and the exception handlers by Held in a same endeavor of debugging with 
predefined breakpoints or marked critical points - as set forth in the rejection has read into the 
claimed above limitations (iii) and (iv); and this has been set forth in section A above also. That 
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is, the claimed hiding step as in (iii) as recited, inter alia, in claim 1 has been perceived as 
amoimting to just executing of previously identified critical segments within exception handlers. 
The very nature of this hiding limitation is not clearly stated in the language of the claim so to 
provide more specific in terms of its implementation so to preclude the combined teachings by 
Kuzara and Held -at the time the invention was made in view of known concept in exception 
handling and breakpoint-based debugging technologies — from rendering the claimed hiding 
implementation obvious; or to make such hiding technique more distinguishing than the 
implementation disclosed by the references as the references also teach identified points where 
exception can be addressed within special code handlers. 

(C ) Applicant has submitted that Held, Cardoza fail to cure Kazura (Appl. Rmrks, pg. 22, 
bottom). Sections A and B above will be referred to address this argument. This argument is 
considered a allegation when the claimed invention is not recited in terms so to distinguish or 
render unobvious the prior art used; especially when the rationale of rejection has set forth 
clearly the reasons why the limitations would have been obvious; against which, Applicant has 
failed to provide clear reasons why such combined teachings would generate adverse effects, and 
so very specifically how. 

Therefore, the claims will stand rejected as set forth above. 

Conclusion 

8. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

Thangadurai teaches breakpoints with set up for identified special handlers for 
foreground debugging or background SMM code execution. 
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Bailey teaches replacing breakpoints with BitMap-based code for handling such 
breakpoints. 

Sangavarapu teaches instrumentation using Inode to address breakpoint-related handlers 
between User space and Kemel execution. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1. 136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS fi-om the mailing 
date of this final action. 

Any inquiry conceming this conmiunication or earlier conmiunications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
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using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 



Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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May 18, 2006 
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